A webform on a web page allows a user to enter data that is sent to a server for processing. Webforms resemble paper or database forms because internet users fill out the forms using checkboxes, radio buttons, or text fields. For example, webforms can be used to enter shipping or credit card data to order a product or can be used to retrieve data (e.g., searching on a search engine).
In addition to functioning as input templates for new information, webforms can also be used to query and display existing data in a similar manner to mail merge forms, with the same advantages. The decoupling of message structure and underlying data allow both to vary independently. The use of webforms for this purpose avoids the problems associated with explicitly creating separate web pages for each record in a database.
Webforms are defined in formal programming languages such as HTML, Perl, PHP, Java, Javascript or .NET (including ASP.NET). The implementations of these languages often automatically invoke user interface idioms, such as grids and themes, minimizing programming time, costs and risks.
Contents |
A form in XHTML or HTML is by far the most common way to use a form online.
The following elements can make up the user-inputting portion of a form:
The sample image on the right shows all of these elements:
These basic elements provide most possible graphical user interface (GUI) elements, but not all. For example, there are no equivalents to a combo box, balloon help, tree view, or grid view. A grid view, however, can be mimicked by using a standard HTML table with each cell containing a text input element. A tree view could also be mimicked through nested tables or, more semantically appropriately, nested lists. Many of these are available through JavaScript libraries.
When data that has been entered into HTML forms is submitted, the form control names and values are encoded and sent to the server in an HTTP request message using method GET or POST, or, historically, via email.[1] The default encoding, MIME type application/x-www-form-urlencoded, is based on a very early version of the general URI percent-encoding rules, with a number of modifications such as newline normalization and replacing spaces with "+" instead of "%20". Another possible encoding, MIME type multipart/form-data, is also available and is common for POST-based file submissions.
XForms is an alternative standard designed to represent the next generation of HTML / XHTML forms. It is also a standard that is generic enough to be used in a standalone manner or with presentation languages other than HTML or XHTML to describe forms in other user interfaces. Unlike HTML / XHTML forms, XForms uses a model–view–controller approach.
An XForms document can be as simple as an HTML / XHTML web form. But XForms includes many advanced features. For example, the form can react in real time and request and retrieve new information while it is still being displayed, without the use of a separate scripting language. The form can specify how its data should be validated or how portions of the form may change depending on data entered in other parts of the form.
Unlike HTML / XHTML forms, XForms is not currently supported on available web browsers.
Forms can be combined with various scripting languages to allow developers to create dynamic web sites. This includes both client-side and/or server-side languages.
The de facto client-side scripting language for web sites is JavaScript. Utilizing JavaScript on the Document Object Model (DOM) leads to the method of Dynamic HTML that allows dynamic creation and modification of a web page within the browser.
While client-side languages used in conjunction with forms are limited, they often can serve to do pre-validation of the form data and/or to prepare the form data to send to a server-side program.
Server-side programs can do a vast assortment of tasks to create dynamic web sites — from authenticating a login through, for example, Lightweight Directory Access Protocol to retrieving and storing data in a database to spell checking to sending e-mail — quite unlike client-side programs. Some server-side program requests must pass through the web server's Common Gateway Interface to execute the program to actually perform the tasks.
The advantage of server-side over client-side is the concentration of functionality onto one computer (the server) instead of relying on each web browser implementing all of the various functions the same. This very problem is quite evident to any developer who writes JavaScript code for multiple browsers.
Scripting languages are the most common server-side programs used for web sites, but it is also possible to run compiled programs.
Some of the scripting languages commonly used:
Some of the compiling languages commonly used:
PHP is one very common language used for server-side languages and is one of the few languages created specifically for server-side programs.
A PHP script may:
The HTML form learns where to pass the data (from the action attribute of the form's HTML element). The target PHP file then retrieves the data either through POST or GET (see HTTP for more information), depending on the programmer's preference. Here is a basic form handler PHP script that will post the form's contents, in this case "user", to the page using GET:
form.html
<html> <body> <form action="form_handler.php" method="get"> User Name: <input name="user" type="text" /> <input type="submit" /> </form> </body> </html>
form_handler.php
<html> <body> <?php /* * This will print whatever the user put into the form on the form.html page. */ $name = $_GET['user']; echo "Hello, ". $name ."!"; ?> </body> </html>
In the above script the $_GET[''] and $_POST[''] commands need to be changed, depending on what is used in the form, however $_REQUEST[''] is used for both so it is more efficient to use for form collection. Note that the value used in input name="" in the html form must be the same as the array value in the $GET[''] expression in the PHP form handler program.
Perl is another language often used for web development. Perl scripts are traditionally used as Common Gateway Interface applications (CGIs). In fact, Perl is such a common way to write CGIs that the two are often confused. CGIs may be written in other languages than Perl (compatibility with multiple languages is a design goal of the CGI protocol) and there are other ways to make Perl scripts interoperate with a web server than using CGI (such as FastCGI or Apache's mod perl).
Perl CGIs were once a very common way to write web applications. But not being specifically designed for web development, Perl is now often viewed as less practical (both for developers and users) than specialized languages like PHP or ASP. This is especially true if Perl modules would need to be installed on the web host or if wanting to use a non-CGI environment that might require extra configurations on the web server. Some web hosts also rely on interpreter-level sandboxing, which while possible with the Safe module, wouldn't be very practical and undoubtly break a lot of scripts considering common practices. Similar considerations might apply to other general-purpose scripting languages like Python or Ruby. For these reasons, a lot of cheap web hosts nowadays effectively only support PHP and web developers often seek compatibility with them.
A modern Perl 5 CGI using the standard CGI module with a form similar to the one above might look like:
form_handler.pl
#!/usr/bin/perl use CGI qw(:standard); $user = param('user'); print header; print html( body( p("Hello, $user!"), ), );
Among the simplest and most commonly needed types of server-side script is that which simply emails the contents of a submitted form. This kind of script is frequently exploited by spammers, however, and many of the most popular form-to-email scripts in use are vulnerable to be hijacked for spamming purposes. One of the most popular scripts of this type was "FormMail.pl" made by Matt's Script Archive. Today, no version of this still frequently used script is considered secure.
To avoid the confusion and difficulty of installing and using scripts, webmasters often use a free forms processing service to get their forms working.
Many companies offer forms "as-a-Service". Usually, these companies give some kind of visual editor, reporting tools and infrastructure to create and host the forms, that can be embedded into webpages. Hosting companies such as Bluehost and Doteasy provide templates to their clients as an add-on free service. Others offer free contact forms installable on any hosted website.